\section{Tests \& Validation}
The two applications have been tested under different conditions and with
different hardware. Below the results of the tests, the validation of
the two applications and some ideas for extensions are shown.

\subsection{Tests}

\subsubsection{Movyzer.application}
The following parts had to be checked regarding its correctness: 
\begin{itemize}
  \item \textbf{the visualization of the data}: Due to the fact, that both, the
  GT3X and the PSG data, are human readable, the correct visualization of the
  data could be verified by comparing the graphs with the files. The GT3X files
  can be converted into a format, which includes a timestamp for every
  measurement:
  \newline
  \fbox{\parbox{1\textwidth}{\code{\ldots \newline
07.04.2010,15:10:00,0 \newline
07.04.2010,15:11:00,789 \newline
07.04.2010,15:12:00,675 \newline \ldots
  }}}
  \newline
  \newline
  Also the PSG data includes timestamp in its files:
  \newline
  \fbox{\parbox{1\textwidth}{\code{\ldots \newline
"Beinbewegung";"N3";"23:28:28";"112";"06.04.2010";"3.5 (15) \newline
"Beinbewegung";"N3";"23:30:07";"115";"06.04.2010";"2 (15) \newline
"Beinbewegung";"N3";"23:30:34";"116";"06.04.2010";"2 (19) \newline \ldots
  }}}
  \newline
  \newline
  Thus, the timestamps and movements could be compared with the graph.
  \item \textbf{the similarity calculation}: The similarity calculation was
  verified by comparing it with files, that only contained a small number of 
  movements. Thereby it was possible to calculate the similarity by hand and to
  compare it with the applications result. Hence and by the examination of
  the source code, the correctness of the similarity could be verified.
\end{itemize}

The performance was tested on several computers, including netbooks as the
Eee PC 1005HA\footnote{1GB RAM, Intel-Atom-N280: 512K Cache, 1.66 GHz, 667 MHz
FSB}. The application ran smoothly, although the LM and PLM extraction needed more
time on weak computers.
\begin{table}[h]
\begin{tabular}{| l | l | l | l |}
	\hline
	Computer & Environment & Analysis time & Graph visualization	\\
	\hline 
	\hline
	Eee PC 1005 HA & 1GB RAM, 1.66 GHz CPU & 20s & smooth \\
	\hline
	Dell inspiron 1520 & 2GB RAM, 2x1.8 GHz CPU & 12s & smooth \\
	\hline
	Athlon 64 X2 3800+ & 4GB RAM, 2x2.0 GHz CPU & 10s & smooth \\
	\hline
\end{tabular}
\caption{Performance of the application on different computers (test file: GT3X
with ca. 1 million entries)}
\label{tab:perf_comparision}
\end{table}

The table \ref{tab:perf_files} shows the RAM usage\footnote{On a Dell
inspiron 1520, 2GB RAM, 2x1.8 GHz CPU, Windows 7} for different files.
\begin{table}[h]
\begin{tabular}{| l | l | l | l |}
	\hline
	File & Period time & Logged events & RAM usage	\\
	\hline 
	\hline
	GT3X  & 1 sec & 61,000 & 10 MB \\
	\hline
	GT3X  & raw (30 ms) & ca. 1 Million & 70 MB \\
	\hline
	PSG  & (irrelevant) & 100 & 5 MB \\
	\hline
\end{tabular}
\caption{RAM usage with different files}
\label{tab:perf_files}
\end{table}

PSG files only need a very small amount of RAM storage, because the movements
don't have to be extracted. More about the GT3X and PSG files in section
\ref{sec:filetypes}.

\subsubsection{Movyzer.mobile}
Several tests have been performed on the mobile application. As a test device a
HTC Magic mobile phone, with Android 2.1, was used. The HTC Magic has a build-in
accelerometer able to log 3 axis.

The most important
requirement for the application, is a high update rate of the accelerometer
data. Therefore the application has been tested under several conditions:
running in foreground mode, in background mode, closing the application etc.
Those different modes didn't affect the update rate, but after some time the
mobile phone enters ``sleep'' mode, which means that the CPU is shut down. As a
consequence the accelerometer data doesn't get updated. The result of such a low
update rate is shown in graph \ref{fig:bad_update_rate}.

\begin{figure}[htp]
\begin{center}
  \includegraphics[width=1\textwidth]{./imgs/screen_mobile_bad.JPG}
  \caption[Accelerometer update rate]{Accelerometer update rate: sleep mode
  (from 13:11:00 till 13:13:30), awake (from 13:13:30 till 13:14:00)}
  \label{fig:bad_update_rate}
\end{center}
\end{figure}
This problem was solved by using a ``wait lock''. A wait lock can forbid the
operation system to shut down certain functionalities as the CPU. In this
implementation the \code{PARTIAL\_WAKE\_LOCK} was used, which ensures that the CPU continues
running. An example of a movement graph logged with the wait lock can be seen in
graph \ref{fig:good_update_rate}. 

\begin{figure}[htp]
\begin{center}
  \includegraphics[width=1\textwidth]{./imgs/screen_mobile_good.JPG}
  \caption{Movement graph logged by a HTC Magic}
  \label{fig:good_update_rate}
\end{center}
\end{figure}
\begin{figure}[h]
\begin{center}
  \includegraphics[width=1\textwidth]{./imgs/mob_accel.JPG}
  \caption[Comparision: GT3X and Movyzer.mobile file]{Comparision: GT3X file
  (upper one), Movyzer.mobile file (lower one)}
  \label{fig:comp_accel_mob}
\end{center}
\end{figure}
Unsing the wake lock an average update rate of ca. 35 ms could be
obtained, which is a surprisingly good value. Nonetheless the update rate can
sink down to $>3$ seconds, when the user initiates a work-intense process on the
mobile phone. One disadvantage of using the wake lock is that the battery drains quickly. Here
the results of some logging tests:
\begin{table}[h]
\begin{tabular}{| l | l | l | l |}
	\hline
	duration & worst update rate & avg. update rate & battery usage
	\\
	\hline 
	\hline
	1h & 4.0 sec & 35 ms & 10 \% \\
	\hline
	2h 45min & 3.4 sec & 38 ms & 25 \% \\
	\hline
	1h & 10.2 sec & 32 ms & 12 \% \\
	\hline
	4h 15min & 4.6 sec & 38 ms & 42 \% \\
	\hline
\end{tabular}
\caption[Movyzer.mobile tests]{Update rate and battery usage for several
Movyzer.mobile tests}
\label{tab:mob_usage}
\end{table}


Figure \ref{fig:comp_accel_mob} shows a comparison between a file created by a
GT3X accelerometer, and a file created by the Movyzer.mobile application. Both
devices performed the same movements and, besides a little time shift, a really
good correlation is visible.

\subsection{Evaluation}
The analysis application was implemented in JAVA, thus it supports
a large variety of computers and operating systems. The application is running
efficiently and fast, thanks to some optimizations. Movements, that have the
same intensity as their adjacent movements, are not displayed. Thus
it is possible to visualize datasets which contain several millions of entries. 

The mobile application was designed for android phones, it supports mobile
phones running with android version 1.6 or higher. An important requirement for the
mobile phones is the availability of a build-in accelerometer and a memory card.
Thanks to the wait lock the mobile application delivers good and useful values.
